       ********    **************************************************
             *    *                                                  *
            *     *      *          The independent guide to BITNET  *
           *      *******                                            *
          *       *******                                June, 1988  *
         *        *      *                                           *
        *         *              *              Volume 2, Number 12  *
       ********   ***************                                    *
                  ***************                                    *
        ***       *              *                                   *
       * * *      *   *                                              *
       * * *      ****                                               *
       * * *      ****                                               *
       * **       *   *                                              *
                  *                                    *             *
           *      *************************************              *
           *      *************************************              *
       ******     *                                    *             *
           *      *                         *                        *
           *      **************************                         *
                  **************************                         *
       ********   *                         *                        *
             *    *         *                                        *
            *     **********                                         *
           *      **********                                         *
            *     *         *                                        *
             *    *                *                                 *
       ********   *****************                                  *
                  *****************                                  *
        ***       *                *                                 *
       *   *      *                                           *      *
       *   *      ********************************************       *
       *   *      ********************************************       *
        ***       *                                           *      *
                  *                               *                  *
       ******     ********************************                   *
           *      ********************************                   *
           *      *                               *                  *
           *      *                                      *           *
       ****       ***************************************            *
                  ***************************************            *
           *      *                                      *           *
           *      *                     *                            *
       ******     **********************                             *
           *      **********************                             *
           *      *                     *                            *
                  *            *                                     *
       ********   *************                                      *
           *      *************                                      *
           *      *            *                                     *
           *      *                                                  *
       ****        **************************************************
1



            *     *              *     *                   *
            **    *         *    **   **       *       *   *
            * *   *  ***  *****  * * * *  ***  ****  ***** ****
            *  *  * *   *   *    *  *  * *   * *   *   *   *   *
            *   * * *****   *    *     * *   * *   *   *   *   *
            *    ** *       *    *     * *   * *   *   *   *   *
            *     *  ****   *    *     *  ***  *   *   *   *   *
       *****                                                    ******


       Christopher Condon    Editor                  CONDON @ YALEVM
       Timothy Stephen       Contributing Editor    STEPHEN @ RPICICGE
       Craig White           Contributing Editor     CWHITE @ UA1VM
       Glen Overby           Technical Assistant   NU070156 @ NDSUVM1
       Gary Moss             Staff Supervisor          MOSS @ YALEVM


       ********************  Contents - Issue 22  ********************


       EDITORIAL PAGE_________________________________________________

       Bitnotes .................................................... 1
       The Human Factor ............................................ 3
       Flames To: .................................................. 7

       FEATURES_______________________________________________________

       CCNEWS - For Newsletter Editors ............................. 9
       LYRICS - The Song Lyrics Server ............................ 10
       PHSERVE - The UIUCVMD Phone Book ........................... 12

       DEPARTMENTS____________________________________________________

       Headlines .................................................. 13
       Helpdesk ................................................... 15
       New Mailing Lists .......................................... 16
       Feedback ................................................... 20
       Policies ................................................... 25


       *  For information on  subscribing to  NetMonth,  submitting  *
       *  articles, sending  letters, and  printing this  file, see  *
       *  the "Policies" section on the last pages of this issue.    *

       -----------------------------------------

                A publication of the BITNET Services Library

                            "Because We're Here."


1

                                                                Page 1


        *********
       *         *  Bitnotes
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  Yale University
       *         *
       *         *  CONDON@YALEVM
        *********


                        "A rose by any other name..."


       Suddenly, the air feels very warm.  Your palms are sweaty, your
       breathing labored.  A nervous twitch is working its way up your
       arm.   You bite your lip.   A chill runs down your spine.   You
       are trying to describe BITNET.

       "It's a... well, sort of a... that is..."

       You want to convey a feeling, a utility,  a sense of community,
       but you find  yourself not quite eloquent  enough.   Words fail
       you, and a thesaurus is nowhere in sight.

       "It's a... kind of... network, see?  With computers..."

       The  computer-guru   will  demand   a  technical   explanation.
       Hardware, link speeds, software.  VM/CMS?  RSCS?  JNET?   NRJE?
       TCP/IP?   Let's wallow  in acronyms,  shall we?    The whole is
       greater than the sum of it's parts, however:

       "It's a... well, more than hardware!  It's people, and..."

       Try to explain  Listserv and mailing lists  to a "non-computer"
       person in a minute or less.  So they TRULY understand?  What is
       there to compare it to in real (i.e. non-virtual) life?

       "It's a... there are these servers with information..."

       True, BITNET is an information service, of a sort.   Some might
       liken  file servers  and name  servers to  similar services  on
       CompuServe, GEnie, or The Source.   That is only small piece of
       picture, however.

       "It's a... Let's see... we send mail and talk to each other..."

       Yes,  it is a tool for  communications.   That is certainly the
       largest part of it.  However, the same could be said for a said
       for a telephone, a television, or a ham radio set.   There must
1

                                                                Page 2


       be something about it that makes  it different from these other
       devices.

       "It's a... we use computers."

       You said that before.

       "It's a... it's people, dammit!"

       People are everywhere.  The NRA is people.   Scientologists are
       people.  Even Republicans are people, allegedly.  Perhaps there
       is something about your people  in particular that makes BITNET
       different.

       "It's a... education and research network."

       Oh.  Eggheads.

       "It's a... No!"

       Let's take a different approach.   Perhaps you can explain what
       BITNET stands for.

       "Got you!  Because It's There, Because It's Time."

       That says a lot.

       ""

       Let's get this straight.  BITNET is an information service.  It
       is a  tool for  communications.   It is  a community  of people
       involved in education and research.

       "Yes, yes, yes!"

       Oh.  Why didn't you just say so?


                      Virtually,

                           Chris Condon@YALEVM


                                                  *
       *******************************************
       *******************************************
                                                  *
                                      *
       *******************************
       *******************************
                                      *
1

                                                                Page 3



        *********
       *         *  The Human Factor
       *         *
       *         *  by T. D. Stephen
       *         *
       *         *  Rensselaer Polytechnic Institute
       *         *
       *         *  STEPHEN@RPICICGE
        *********


       There is  an old  bromide,  perpetually  re-hashed in  freshman
       communication courses  throughout America  each Fall  semester,
       that says, "you cannot not communicate".   Usually presented as
       an hypothesis,   students are challenged  to agree  or disagree
       with  it.    After  sufficient deliberation  and  debate,   the
       instructor  reveals that  "you cannot  not  communicate" is  an
       accepted minor tenet of modern communication theory.   Everyone
       knows that  you cannot not  communicate because the  absence of
       communication itself conveys meaning;  e.g.,  if a friend won't
       speak to you,   you suspect that she's probably  trying to tell
       you that you've done something wrong.

       Suddenly BITNET  calls this into  question.   I can't  think of
       another communication  system that better demonstrates  so many
       ways in  which you *can*  effectively not communicate  and that
       shows so  clearly how it  is sometimes virtually  impossible to
       make any sense from communication's absence.

       A good  example occurs when  a new  node has been  connected to
       BITNET  before  routing  tables at  existing  sites  have  been
       updated.    As  I  understand it,   the  routing  tables  allow
       computers to  know which  path to take  in sending  messages to
       each  other.    People from  the  new  node can  send  messages
       throughout the network because systems personnel there received
       a copy of the latest routing  table upon joining the net.   But
       recipients cannot  communicate back  and,  generally,   neither
       sender nor receiver understands what the devil is going on.

       I've  seen  this periodically  when  someone  from a  new  node
       attempts  to  contact   Comserve@Rpicicge,   the  communication
       studies information system.   Jones@Newnode sends the following
       message on day 1:  "Help".    Comserve responds but the network
       software rejects  the message before  it gets very  far,  often
       before it leaves RPI.   The new user repeats the "Help" message
       on day 2.   On day 3 the following:  "Hello?".   Then on day 4,
       "Why don't you respond to me? Please let me know what I'm doing
       wrong."  That's the end of it;  Comserve usually never receives
       a message from Jones@Newnode again.   Too bad the network can't
1

                                                                Page 4


       provide  Jones with  feedback  that  his/her message  traversed
       beyond a point of no return.

       If information makes the world go  around,  then it is feedback
       that  keeps it  in  its  orbit.   Feedback  corrects,   aligns,
       adjusts, modulates, attunes; it is the system's defense against
       entropy.    No  system,   mechanical  or  human,   can  perform
       effectively  or for  long unless  its designers  have built  in
       methods for  it to monitor and  correct its own  behavior.   It
       must have dedicated  sub-systems that exist to  provide a means
       for testing the continued validity  of the original assumptions
       upon  which  the  system  was   built  and  for  relaying  this
       information appropriately.   With provision  for such feedback,
       it  is possible  for systems  to adapt  themselves to  changing
       circumstances.    Without  it,   the system  is  an  inflexible
       dinosaur  and  will begin  to  break  down as  its  environment
       changes.

       While  there  are  many points  at  which  mechanical  feedback
       systems have been  built into BITNET and  its various services,
       there are several critical points at which they are missing and
       their absence can be inconvenient and frustrating.  Craig White
       anticipated this  issue in  his "Flames-To"  column last  month
       when he identified one of BITNET's principle problems: its lack
       of an  effective feedback  mechanism assuring  minimum time  to
       recovery when a link goes down.  Craig noted, as have others no
       doubt,  that there is a great deal of variance in the degree of
       vigilance  and responsibility  that site  personnel display  in
       monitoring   the   status   of    their   BITNET   connections.
       Unfortunately,   the   network  software  that  allows   us  to
       communicate doesn't do a good job  of notifying anybody when it
       loses a connection to another computer.  A good version of this
       software would fix itself,  an adequate version would trigger a
       flashing light or an audible alarm.    Based on what I've seen,
       the version we need on BITNET is one that starts deducting from
       the salary of  the person responsible for  maintaining the link
       until it is restored.

       One  feedback  system  --  the Linkfail  mailing  list  --  was
       established  to  help  head  off a  portion  of  the  confusion
       generated by this type of situation.   The idea behind Linkfail
       is that when a  site knows in advance that it  will not be able
       to provide  service for a  period of  time (due to  a scheduled
       campus power outage, for example) someone is supposed to send a
       note to Linkfail  to let the rest  of us know about  it.   Good
       idea.   In practice, however,  this system doesn't work as well
       as it  should.   One problem  is that  not all sites  bother to
       inform  Linkfail,   not  even  all of  the  central  ones  that
       virtually everyone depends on (Yale,   CUNY,  Ohio State,  Penn
       State, etc.).   Another problem is that announcements posted to
1

                                                                Page 5


       Linkfail are often not channeled  to users.   It really doesn't
       do users any  good if,  after the systems  programmers find out
       from Linkfail  that the network  will be unavailable  for three
       days next week, they don't tell users at their site about it.

       Obviously,  it would be better if  users could be provided with
       more feedback  about the status of  the network.   But  in many
       cases  feedback loops  need to  be bi-directional,   connecting
       those who provide BITNET services (file servers,  name servers,
       mailers, gateways, list servers,  etc.)  and the people who use
       them.  Both could profit from each other's feedback.  Those who
       access  services   could  find  out   how  to  use   them  more
       productively and efficiently;  those who provide services could
       find out  how to  improve them.    Unfortunately,  many  BITNET
       services have  not been  provided with  an adequate  system for
       human feedback.

       Take as  an example  the common  Listserv occurrence  of people
       sending subscription  requests to  the address  of the  mailing
       list instead  of to  Listserv itself.    Sometimes hundreds  of
       copies of the request are  delivered to other subscribers,  the
       subscription request  does not  itself get  processed,  and  no
       feedback is  provided to the  would-be subscriber (making  it a
       little  difficult to  learn from  the  mistake).   Since  there
       appear to be difficulties in programming Listserv to detect and
       respond to these  errant requests,  there should  be,  but most
       often is  not,  a human monitor  -- someone who can  supply the
       feedback  that  the user  needs  in  order  to use  the  system
       productively.   In  addition,  there  should be  an avenue  for
       *users* to  supply feedback to  those who provide  and maintain
       the Listserv software system.  There is a "list" named LSTSRV-L
       and it provides this function for Listserv operators;  they use
       LSTSRV-L to communicate among themselves  and with Eric Thomas,
       the Wunderkind behind Listserv.   However,  what's lacking is a
       similar  feedback loop  connecting Listserv's  users and  local
       Listserv operators.

       As far as I can tell, there has been no formal effort to assess
       users' experiences with  Listserv,  to find out  what they like
       about it and what they find annoying.   Don't misunderstand,  I
       don't  mean  to  single out  Listserv  for  special  criticism;
       Listserv merely  offers a convenient  example,  one  with which
       most of  us are familiar.   Services  on BITNET that  provide a
       point  of  human  contact  or have  attempted  to  gather  user
       feedback  through some  other mechanism  are  a tiny  minority.
       This phenomenon  seems especially dangerous given  the computer
       industry's well known history of hardware and software ventures
       that flop  after having  been designed  without adequate  input
       from potential  users or  having gained  a reputation  for poor
       consumer relations.
1

                                                                Page 6


       One reason that  people developing or operating  BITNET and its
       services may be  reluctant to provide mechanisms  for gathering
       user  feedback  is  that  managers   may  not  always  place  a
       sufficient premium on this sort of  effort.   The word may come
       down to  "provide users  with e-mail  access",  rather  than to
       "provide users  with an  e-mail system  that *users*  will find
       accessible."  Basically,  the  problem  is  one of  leadership.
       Certainly most schools that belong to BITNET have the technical
       and human resources to provide  a higher grade of user-oriented
       service;  however,   without leadership from site  managers and
       ultimately from BITNET's main administrative body -- the BITNET
       Board of Trustees -- these resources  may never be brought into
       play.

       Modeling is one  of the most effective forms  of leadership and
       this is where the Board of  Trustees could perform an important
       service.   They should provide a  visible example of responsive
       and  open  communication  with the  BITNET  user  community  by
       sustaining an  active effort to  solicit feedback  about BITNET
       and recommendations for its improvement.   However, the present
       system  used  by  the  Board  for  gathering  feedback  has  no
       realistic provision  for obtaining input from  BITNET's general
       user population.   If a user has a question, a suggestion, or a
       complaint or wishes to have a  voice in policy matters,  he/she
       is  expected to  channel  this through  the  local BIR  (BITNET
       Institutional Representative).   This individual is supposed to
       pass it along to the Board.

       Whoever thought  this system up was  either naive about  day to
       day business on  BITNET,  conceived of BITNET  as the exclusive
       province of computer center personnel,   or wanted to create an
       appearance of  openness while  guaranteeing that  policy making
       would proceed in  an environment effectively closed  to outside
       input.   Take a guess:  How many of BITNET's users do you think
       know  who their  local BIR  is (or  their Information  Services
       Representative  or their  Technical  Representative,  for  that
       matter)?  How many sites routinely let new users know who these
       people are and that they are responsible for conveying feedback
       to  the Board?    How  many BIRs  really want  to  act in  this
       capacity  and have  demonstrated  so  by canvassing  users  for
       input?

       I once had a professor who nurtured his reputation as a phrase-
       maker  and  one of  his  favorites  quips  was "the  facts  are
       friendly." What  he meant by this  was that those  who actively
       solicit feedback  will always do  better than those  who don't,
       even if  the feedback is  negative.   Only systems  that become
       aware of their problems will be able to correct them.  So let's
       see what  we can do to  open dialog between  BITNET's services,
       users, and agencies.   Let's come out from behind the automated
1

                                                                Page 7


       servers and isolated decision-making structures and engage in a
       little perception testing.   Moreover,  let's call on the Board
       of  Trustees  to   provide  a  positive  model   for  effective
       communication,  one  that enfranchises all of  BITNET's diverse
       groups of users.

       ***************************************************************

       I received a  large amount of mail in reaction  to last month's
       column on making BITNET addresses  easier for humans.   Much of
       this mail was from computer center staff who are sympathetic to
       the problem and would like to  find solutions and some was from
       people who have solutions to offer.   Suggestion:  write to the
       listserv operator  at Bitnic,  and ask  for a new "list"  to be
       established  for discussion  of approaches  for resolving  this
       problem.   Send me a note when that's accomplished and I'll ask
       Editor  Condon to  announce the  list address  in next  month's
       issue.


        *********
       *         *  Flames To:
       *         *
       *         *  by Craig White
       *         *
       *         *  University of Alabama
       *         *
       *         *  CWHITE@UA1VM
        *********


       Hello again,

       This month  the mail has really  poured in.   My in-box  was so
       full  at times  that  it just  had to  sit.    I thought  about
       different  ways  to deal  with  this  dilemma but  really  just
       couldn't come up with  a very good way to do  that.   I did get
       most of the reading done except for some of the digests.   This
       month has been a very reliable  one in terms of connectivity in
       my limited area;  I appreciate all the hard work that goes into
       that,  folks.    This month's  flame is  about,  of  all things
       FLAMES.

       As I read mail from the various lists,  I often see flames that
       are  not  clearly  marked  as   such.    Because  we  sometimes
       misinterpret what we read, I would say that only half of what I
       consider  to be  flames actually  are.    Most of  us are  well
       acquainted  with  the phenomena  of  misinterpretation.    Take
       computer manuals for  instance;  I know that many  times I have
       had problems getting programs to run or commands to work simply
       because I misinterpreted what I read in a manual.
1

                                                                Page 8


       With electronic mail,  this misinterpretation  seems to be even
       more prevalent, and many times with terrible consequences.  For
       instance,  if someone misinterprets one  of your postings,  you
       might get flamed for it.    Often,  we feel personally attacked
       when this  happens,  and there is  a tendency to  overreact and
       send an  inappropriate mailing to  the sender of  the offending
       posting.   Or even worse,  to the whole list if we feel that we
       have been sufficiently slighted.

       I suppose that what we really need  to keep in mind is that for
       most people,   mailing to a list  is something they  didn't put
       much thought into.    Often,  it is a description  of a problem
       quickly typed  and then  sent on it's  way.   Sometimes  in the
       description of the  problem the sender neglects  to mention the
       pertinent  facts  and  in  response   someone  mails  a  really
       condescending  letter back  to the  group,  maybe  to make  the
       person feel that  their problem is somehow too  trivial for the
       group.  Many  times this is repeated  for 10 - 20  times before
       everyone feels that they have thoroughly humiliated the foolish
       person.  The result is usually that even though the problem was
       easy to solve,   no one remembered to  put the answer to  it in
       their response.

       I think that in the above case, the responder who rags the poor
       guy for  being an  idiot,  should ALWAYS  make sure  that their
       response is preceded by some kind of FLAME marker.  It could be
       as cute as  "get out your asbestos underwear",  or  as terse as
       ***FLAME ON***.   The author of  such flames should always make
       it perfectly clear to whom they are about to flame, and also to
       the whole list if it just has to be made public,  that they are
       about to engage  in a display of emotions so  that everyone can
       get the right perspective about the whole event.  If you happen
       to be on the receiving end of a flame, try to remember that you
       somehow managed to trigger an emotional response on the part of
       the flamer and you  should keep that in mind as  you read their
       response.    You as  the recipient  of the  flame should  avoid
       sending a flame back  to your flamer for at least  one night of
       sleep.   It seems  that many  times flames  just keeps  getting
       bounced back and forth until it's an inferno with neither party
       able to  do anything but  fume and send  out more fuel  for the
       other to use.   By giving yourself a little time between flames
       you give  yourself and the  sender time  to mull over  what has
       been said,  develop  a new attitude,  or you  might even decide
       that it's not even worth the  trouble to compose a response and
       send it off.

       Cooling off,  I have an LDBASE update.   It seems that LDBASE's
       ability to  search notebooks is totally  up to the  list owner.
       So if you're trying to use LDBASE  to help out your in-box as I
       am,  contact list owners about changing their lists so that you
1

                                                                Page 9


       don't have to be signed up  to peruse their notebooks.   Thanks
       to  Eric Thomas  for this  LDBASE  clarification.   As  always,
       flames, questions, comments to CWHITE@UA1VM.


        *********
       *         *  CCNEWS - For Newsletter Editors
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  Yale University
       *         *
       *         *  CONDON@YALEVM
        *********


       CCNEWS is  a weekly  electronic magazine  for campus  computing
       center newsletter editors.  In it they discuss common interests
       and concerns  about delivery of  news and  information.   These
       include desktop publishing,  printing,   operational aspects of
       developing newsletters,  writing,  and computing-related issues
       relevant to campus computing center information dissemination.

       Even if you are not a newsletter editor,  but are interested in
       desktop or  electronic publishing,   CCNEWS holds  a wealth  of
       information.  A typical piece of information:

       "Over  the years  I have  discovered that  the programmers  and
       consultants  here generally  think  they  already know  how  to
       write.   However, often what I get from them is not necessarily
       what I want  nor in the form/  style I use in  Ã•my newsletterÃ¥.
       Also,  many  of them  take issue  when their  contributions are
       edited  into   completeness  and   conformity.   I   think  the
       programmers  and  consultants  here do  not  view  writing  for
       Acronyms  as one  of their  job requirements  and would  rather
       stick to  what they  like doing  -- programming  and front-line
       consulting.   Before developing a seminar to  teach these folks
       a new skill, I would make sure they wanted to learn!"

       Listserv  has  also enabled  the  CCNEWS  staff to  develop  an
       "Articles  Archive" of  material  submitted  by subcribers  and
       available for downloading for research  or reprint (with proper
       attribution,  of course).  The Archive currently contains items
       on  topics such  as piracy,   viruses,  electronic  networking,
       stylesheets, microcomputer maintenance, etc.

       You  can  receive  a  list of  thes  articles  by  sending  the
       following  command  to  LISTSERV@BITNIC via  mail  or  message:
       INDEX CCNEWS.
1

                                                               Page 10


       Likewise,  you can subscribe to  CCNEWS by sending the command:
       SUB CCNEWS Your_Full_Name - Institution.  For example:

            SUB CCNEWS Henry Chmielewski - Yale University


        *********
       *         *  LYRICS - The Song Lyrics Server
       *         *
       *         *  by the Lyrics Manager
       *         *
       *         *  University of Massachusetts
       *         *
       *         *  LYRMAN@UMASS
        *********


       LYRICS@UMASS is a file server storing song lyrics.   It accepts
       commands by  mail only.    The format  for a  request from  the
       lyrics server is as follows:

            Command/param1=option/param2=option/param3=option

       There are 3 commands available for requests.

            Lyrics - prints lyrics
            Albums - prints album titles and authors
            Songs  - prints album titles, authors, and songs on albums

       These commands will accept 3 parameters.

            /Author=xx   restricts search to work of author xx
            /Album=xx    restricts search to album xx
            /Song=xx     restricts search to song titled xx


       Examples:

            Albums/Author=Peter Gabriel
            lists album titles of Peter Gabriel

            Lyrics/Album=So
            prints lyrics of any album entitled So

            Songs/Album=So
            lists all songs on any album entitled So

            Lyrics/Song=Red Rain
            lists lyrics of any song entitled Red Rain
1

                                                               Page 11


       Multiple parameters are also valid.  For example:

            Lyrics/Album=So/Song=Red Rain
            lists lyrics of a song Red Rain that is on album So

            Albums/Author=Peter Gabriel/Song=Red Rain
            lists album by Peter Gabriel that contains song Red Rain


       Requesting Lyrics:

       To make a  request to the server,  simply  type the appropriate
       command line in the body of a message to LYRICS@UMASS.   If you
       would like to make a request from  the server,  a good place to
       start would be sending just Albums  (The Albums command with no
       parameters) which will list all album entries.

       Multiple requests  can be  made in  one letter  by typing  each
       command set on a separate line.  The subject line is ignored by
       the server.

       The server  checks for mail every  ten minutes,  so  a response
       shouldn't take any  longer than that under  most circumstances.
       Network  replies obviously  depend on  other  factors as  well.
       Some requests may entail lengthy responses.  Users with minimal
       file space should be aware of this.   Note:  a * next to a song
       title indicates that  it is an instrumental,  or  no lyrics are
       available for it.

       Advanced help is  available by typing HELP/option  where option
       is one of the following available topics:

            FORMAT - instructions for contributing lyrics
            SEARCH - describes the wildcard string search capability

       Contributions are always encouraged and appreciated.

       Please send all questions,  comments,  corrections,  additions,
       and whatnot to:  Lyrics Manager, LYRMAN@UMASS.


                                                  *
       *******************************************
       *******************************************
                                                  *
                                      *
       *******************************
       *******************************
                                      *
1

                                                               Page 12


        *********
       *         *  PHSERVE - The UIUCVMD Phone Book
       *         *
       *         *  by Charley Kline
       *         *
       *         *  University of Illinois
       *         *
       *         *  KLINE@UIUCVMD
        *********


       PHSERVE@UIUCVMD is a database of faculty,  students,  and staff
       at the University of Illinois at Urbana-Champaign.   The server
       accepts interactive  BITNET message  (not files  or mail)   and
       looks up  names in  an online  copy of  the phone  book at  the
       University  of  Illinois at  Urbana-Champaign.    Specifying  a
       single name will  look up entries with a first  last,  or email
       name.  Specifying multiple names will force returned entries to
       match each name given.

       By default,  queries are assumed to  refer to the name field of
       the entry.   Therefore, a query of "john doe" looks for entries
       whose name  contains "john"  and "doe."  Fields other  than the
       name  field   must  be   specified.    For   example,   "dorner
       address=DCL" would  return entries which contained  "dorner" in
       the name and whose address contained "DCL."

       Matching is done on a word-by-word  basis.   That is,  both the
       query  and  the  entry  are broken  up  into  words,   and  the
       individual  words are  compared.   Although  the nameserver  is
       insensitive  to case,   it otherwise  requires  words to  match
       exactly; "john" does *NOT* match "johnson," for example.

       Only  entries that  match *ALL*  of the  specifications in  the
       query are returned.   For example,  "charles kline" will return
       all  entries with  *BOTH*  "charles" and  "kline"  in the  name
       field.   Note  in particular  that this  query is  identical to
       "kline charles."

       A  certain set  of  fields are  returned  by  default.   It  is
       possible to ask for different fields in a query.   This is done
       by specifying the "return" keyword,   and listing the fields of
       interest.  For example, a query of "steven dorner return email"
       would return only the electronic mail address of Steve Dorner.

       Results  are returned  by BITNET  interactive  messages if  the
       reply is sufficiently short;  otherwise they are sent in a file
       called "PHSERVE REPLY."

       Queries   may  contain   any  combination   of  the   so-called
       metacharacters, *,  ?,  and Ã•Ã¥.   Metacharacters can be used to
1

                                                               Page 13


       specify  wildcards  or  alternates  within  a  query.    People
       familiar  with  UNIX  will recognize  these  metacharacters  as
       identical to those recognized by the UNIX shell.

       The metacharacter "?" represents exactly one unknown character.
       Thus,   "johns?n"  matches  "johnson"  and  "johnsen"  but  not
       "johnsenn."

       The metacharacter "*" can be used in a request to indicate zero
       or more unspecified characters.  For example, "kl*e" will match
       "kline",  "klemme",  and "kluge".    Be warned,  however,  that
       queries resulting in too many matches will be refused.

       Square  brackets represent  a match  of one  of the  characters
       inside the  brackets.   For  example,  "johnsÃ•oiÃ¥n"  will match
       "johnsin" and "johnson" but not "johnsen" or "johnsoin."

       For   examples    and   more   detailed    information,    send
       PHSERVE@UIUCVMD the command "?".


        *********
       *         *  Headlines
       *         *
       *         *  Smaller specks of news...
       *         *
       *         *  ...but not unimportant!
       *         *
       *         *  Send them to BITLIB@YALEVM
        *********


       * Hey!:  Please remember that the file  server NYSHARE@WEIZMANN
       will  only  accept  commands  sent by  interactive message, not
       mail.  Too many mail messages will result in a server shutdown.

       * Listserv  news:   Goz Lyv tells  us of yet  another FILELIST.
       The HELPCONV filelist on  LISTSERV@BYUADMIN stores (what else?)
       the HELPCONV software package.

       * Mike Roberts, Vice President, Networking, EDUCOM:  "I am very
       sorry to  announce that Judy Molka  will be leaving  the BITNIC
       staff in August so that she can pursue a Master's degree in the
       Univ of  Pittsburgh Telecommunications program.    Her talented
       and dedicated contributions  to BITNET are known  far and wide.
       I am  sure you will  join me in wishing  her well as  she takes
       this  important  career  step.    We  are  mailing  a  position
       announcement for a Network Services  Consultant to replace Judy
       to  all  BITNET  Institutions   Representatives.    We  solicit
       applications from all qualified individuals.  If you are not an
1

                                                               Page 14


       IR and would like a copy  of the position announcement,  please
       contact    Elizabeth    Kilcoyne   of    the    BITNIC    staff
       (KILCOYNE@BITNIC)."

       * TRICKLE:    A copy  of  the  TRICKLE  file  server  has  been
       installed in  Denmark.   This  server is  the same  as the  one
       described  in the  May issue  of NETMONTH  by Turgut  Kalfaoglu
       (TURGUT@TREARN).    Our    TRICKLE   can   be    contacted   on
       (TRICKLE@DKTC11).  TRICKLE provides you with directory listings
       and file from the SIMTEL20 personal computer software archives.
       To get in touch with TRICKLE you can send it the command /HELP.
       Thanks to Alan Jacobsen for this update.

       * NICSERVE@BITNIC  is  being  replaced:    All  files  in  this
       directory  are  now available through LISTSERV@BITNICs  NETINFO
       FILELIST.   Please use LISTSERV@BITNIC in  the future to obtain
       these files.   On September 1st  1988,  NICSERVE will no longer
       have access to these files, instead a note recommending the use
       of LISTSERV@BITNIC will be the only response to commands.

       Since the BITNIC Staff cannot change  the format of the NETINFO
       FILELIST (because  certain operations  of the  server are  tied
       into the format  of the index),  the  following procedures have
       been initiated to support both old and and new index formats.

       They will presently maintain the hand-edited NICSERVE INDEX and
       a newly  created NETINFO INDEX (an  exact copy of  the NICSERVE
       INDEX),  along with the NETINFO FILELIST.   After the September
       1st replacement  of NICSERVE  by LISTSERV,   the files  NETINFO
       INDEX and NETINFO FILELIST will be maintained.

       To get the "old" format index, you can do one of 3 things:

            Send the command INDEX to NICSERVE@BITNIC.
            Send the command GET NICSERVE INDEX to NICSERVE@BITNIC.
            Send the command GET NETINFO INDEX to LISTSERV@BITNIC.

       To get the "new" format index, you can do this:

            Send the command INDEX NETINFO to LISTSERV@BITNIC.
            Send the command GET NETINFO FILELIST to LISTSERV@BITNIC.

       Again,  after September 1st,   commands sent to NICSERVE@BITNIC
       will not work.


                                                  *
       *******************************************
       *******************************************
                                                  *
1

                                                               Page 15


        *********
       *         *  Helpdesk - a Question and Answer column
       *         *
       *         *  by Marc Shannon
       *         *
       *         *  Carnegie Mellon University
       *         *
       *         *  Send your questions to HELPDESK@DRYCAS
        *********


       Well,  here I am!  All ready for my first column!  (I've always
       wanted to be in "print",  but I had figured that it would be on
       a National  Security Administration  print-out.)  I  guess I'll
       just jump right in...

       *Q* How  does interactive  messaging affect  file transfers  on
       BITNET?

       *A* Messages,  either as a "message" between two users (with or
       without Relay) or as a "command" from a user to another node on
       BITNET, can be considered as small, urgent files.  As a file is
       being  transmitted on  a BITNET  link,   it is  broken up  into
       packets.   These packets  are used to fill up a  "block" on one
       computer and are then transmitted to the other computer.

       When a  message is to be  transmitted across that link,   it is
       inserted  into that  block (taking  up  the space  that a  file
       packet might have  used).   More messages,  less  file packets.
       This is why,  generally,  large files  may take overnight to be
       transmitted across heavy-traffic links  (such as PSUVM-CUNYVM).
       During the  day,  many  small files (such  as mail  files)  are
       enqueued and get sent before the  larger files.   Then,  in the
       evening and early night,  people get on Relay and send messages
       (quite a few) across these links.  Some large files may not get
       a chance  to begin transmission until  two or three  o'clock in
       the morning.

       *Q* Besides RELAY, what other services does BITNET provide?

       *A* BITNET  provides  one  of the  best  services  just in  its
       existence:   the ability  to  communicate  (either online  with
       messages or offline with mail) to friends and colleagues across
       the WORLD.    (Mithrandir and  I spend  time occasionally  just
       marvelling at the power we have at our fingertips.) (Ed.  note:
       BITNET is really just the United States.   The larger-scale NJE
       network includes BITNET, EARN (Europe), NetNorth (Canada),  and
       AsiaNet.)

       The file BITNET SERVERS (sent along with NetMonth and available
       in the  archive locations listed at  the end of  this magazine)
1

                                                               Page 16


       lists many,   if not  all,  of the  servers running  on BITNET.
       Through the file  servers and mailing lists  available,  you'll
       find many things to do.

       *A* (additional)   to last month's  question "Can all  nodes on
       BITNET send and  receive interactive messages?" It  has come to
       our attention  that there are  non-IBM programs  available that
       can be  installed which  allow TSO  users to  send and  receive
       interactive  messages.   If  you  would  like to  receive  more
       information about this,  send mail to HELPDESK@DRYCAS and we'll
       pass the information on to you.


        *********
       *         *  New Mailing Lists
       *         *
       *         *  from List-of-Lists
       *         *
       *         *  by Rich Zellich
       *         *
       *         *  ZELLICH@SRI-NIC.ARPA
        *********


       AIX-L

       This list is  intended for the discussion of  the AIX operating
       system,   IBM's Unix  solution  for  small and  large  computer
       systems.   Initially,  this list will be used for dissemination
       of information and technical details of AIX on all levels.   It
       may be  necessary to  break this list  down into  machine types
       that AIX will run on.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions, etc., should be sent to the Moderator.

            Moderator:
            Michael R. Gettes 


       ANDREW-DEMOS

       A mailing  list to  be used  simply for  demonstrations of  the
       Andrew system software.   You should not subscribe to it unless
       you expect to be reading it with the Andrew Message System,  as
       messages  will come  to the  list in  full multi-media  format.
       Indeed,  we encourage  people to post lots  of neat animations,
       music, raster images, and the like to this list.

       To be  added   to  the  list,    send  mail   to  ANDREW-DEMOS-
1

                                                               Page 17


       REQUEST@ANDREW.CMU.EDU.   To submit new items to the list, just
       send them to ANDREW-DEMOS@ANDREW.CMU.EDU.

            Coordinator:
            Nathaniel Borenstein 


       ANTHRO-L

       This  list deals  with discussions  of  various techniques  and
       fields of research in Anthropology.    Some suggested topics of
       discussion are:

          - Computation in anthropology
          - Graphics in archaeology
          - What programs anthropologists are using at various places
          - Where centers of computer interests are in anthropology
          - Anglo-Saxon cemeteries
          - Palaeodemography
          - Some spirited words on political economy
          - The development of Anglo-Saxon cemeteries
          - The Northumberland landscape
          - The population of Anglo-Saxon England

       To add  yourself to  the list,  send  the following  command to
       LISTSERV@UBVM  via   mail  or   message:   SUBSCRIBE   ANTHRO-L
       Your_Full_Name

            Coordinator:
            Patrick G. Salsbury 


       BMDP-L

       Discussion group for users of BMDP software.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems,   questions,  etc.,   should be  sent to  one of  the
       Coordinators.

            Coordinators:
            Michael Walsh 
            Sander Wasser 


       CONS-L

       This group  provides a  forum for  university computing  centre
       consultants  to  discuss  such   issues  as  problem  tracking,
       resource management, training, and consulting strategies.
1

                                                               Page 18


       All  requests  to  be  added to  or  deleted  from  this  list,
       problems,   questions,  etc.,   should be  sent to  one of  the
       Coordinators.

            Coordinators:
            Michael Walsh 
            Sander Wasser 


       ENVBEH-L

       Mailing list on Environmental  Behavior:  Environment,  Design,
       and Human Behavior.   ENVBEH-L is a  discussion on a variety of
       topics concerning  the relations of  people and  their physical
       environments,  including architectural and  interior design and
       human behavior,  environmental stress (pollution,  catastrophe)
       and behavior,   human response to  built and  natural settings,
       etc.

       To subscribe,  send the  following command to LISTSERV@POLYGRAF
       via mail or message:  SUB ENVBEH-L Your_Full_Name.

            Coordinator:
            Tony Monteiro 


       IFPHEN-L

       Discussion group on Interfacial  Phenomena (Group 1c,  American
       Institute  of   Chemical  Engineers).     Meetings,   articles,
       software,  theories,  materials,  methods,   tools,  etc.,  are
       discussed.

       To subscribe, send the following command to LISTSERV@WSUVM1 via
       mail or message:  SUB IBMTCP-L Your_Full_Name.

            Coordinator:
            Richard L. Zollars 


       MBA-L

       The MBA-L student curriculum discussion mailing list is for any
       information or news about  MBA programs,  their administration,
       problems,   issues,   questions,   etc.;  it  is  intended  for
       administrators, faculty, and MBA students.

       To subscribe, send the following command to LISTSERV@MARIST via
       mail or message:  SUB MBA-L Your_Full_Name.

            Coordinator:
            Bob Comerford 
1

                                                               Page 19


       STAT-L

       An open discussion group dealing with statistical consulting at
       university computing centres.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems,   questions,  etc.,   should be  sent to  one of  the
       Coordinators.

            Coordinators:
            Michael Walsh 
            Sander Wasser 


       VIRUS-L

       Mailing  list for  the discussion  of  computer viruses.    The
       discussion originally focused  on IBM PC viruses  but Mac,  and
       other types of, viruses are sometimes discussed as well.

       Archives are available,  as is a  file called DIRTY DOZEN which
       lists a number of viruses, trojan horses,  and pirated programs
       for the IBM PC.

       To subscribe,  send the  following command to LISTSERV@LEHIIBM1
       via mail or message:  SUB VIRUS-L Your_Full_Name.

            Coordinator:
            Jig Shaffer, Jr. 


                                                  *
       *******************************************
       *******************************************
                                                  *
                                      *
       *******************************
       *******************************
                                      *

                                                                 *
       **********************************************************
       **********************************************************
                                                                 *
                                                 *
       ******************************************
       ******************************************
                                                 *
1

                                                               Page 20


        *********
       *         *  Feedback
       *         *
       *         *  a Letters column
       *         *
       *         *  "Back in the USSR?"
       *         *
       *         *  Send your letters to BITLIB@YALEVM
        *********


       From:     Ted Herman
       Subject:  Suggestions

       I'd like to offer some ideas for NetMonth:

       1.   I've seen several recommendations of "Toward an Ethics and
       Etiquette for Electronic Mail" in issues of NetMonth.   Yes,  a
       PREscriptive work on the manners of electronic mail is a worthy
       effort and I can well understand why you recommend it.  But I'd
       also like to see,  on a  continuing basis,  DEscriptive work on
       the manners of electronic mail.  I'm no anthropologist, but I'm
       entertained by comments like:

        > I'd be interested to know the mix of people who squaked
        > on USENET.  What kind of users are they on USENET?

          ...

          USENET, on the other hand, was always the "wild and wooly"
          bunch.  Much less quick to "authoritarian" standards --
          much more libertarian in the belief that not only does
          EVERYBODY have an opinion, but that it is one's DUTY to
          express that opinion.

          ...

          If one goes to "usenix" one sees "typical" college students
          in the majority -- sandles, shorts and t-shirts.  If one goe
          to "/usr/group" one finds the "typical" business type --
          shoes, long slacks and Grateful Dead T-shirts.

          ( the above excerpted from a recent letter in UG-L )

       2.   On much the same theme, I would REQUIRE that announcements
       and reviews of mailing lists contain edited portions of typical
       letters.   Have you noticed how  samples included in reviews of
       Whole Earth Review enhance the reviews?    I find that a "Time-
       Life" keyword  abstract of  a mailing  list's masthead  doesn't
       show me the  personality of the list.   Wouldn't it  be nice to
1

                                                               Page 21


       see  some  typical  samples,  synopsis  of  recent  topics  and
       controversies, rather than go to the trouble of subscribing and
       finding out for yourself?

       Usual  disclaimer/apology:   please  accept  these comments  as
       constructive criticism, I do not mean to deprecate your effort,
       keep up the good work, rah rah rah, etc.

       *Editor's Note*  Unfortunately there  are several  obstacles in
       providing such a service (although  it would be nice).   First,
       the lists we announce are new,  so there would be often little,
       if anything, to review.  The big problem however, would be that
       the length of  these reviews would add to  an already too-large
       NetMonth.  Keep the ideas coming!


       From:     David Benson
       Subject:  Addresses

       I find most of NetMonth very  interesting and I appreciate that
       the articles are signed with names.   But I find it frustrating
       that only  BITNET addresses are  used.   UA1VM doesn't  tell me
       much.   Maybe I should know where  Craig White comes from,  but
       I'm a  relative newcomer to BITNET  and don't.   Maybe  I'm not
       supposed to know where Craig White comes from, but why?

       Tim Stephen's article  on the problem of user ids  makes a good
       point,  and  I THINK  his address means  he is  from Rensselaer
       Poly,  but  I'm not  sure.   Would  it take  too much  space to
       include "real" addresses  or at least identifiers  for NETMONTH
       contributors?

       *Editor's Note*  See changes this issue.


       From:     Dave Phillips
       Subject:  Bring BITNET to the USSR?

       A recent article in Netmonth suggested  that efforts be made to
       bring BITNET to the USSR.

       This would be a  great idea if and only if  access to the links
       at the Soviet side were not  rigidly controlled and rationed to
       "reliable" people.

       A more workable trial might be  Poland,  which has a much freer
       society (despite the  authorities)  than the USSR's,   a *very*
       Western popular outlook,  a large  number of young people eager
       to work with computers,  and (like the USSR)  a good percentage
       of students know English and/or other European languages.
1

                                                               Page 22


       Since Poland has entered the  International Monetary Fund,  and
       since the  PPR has (like  the USSR)  participated  nominally in
       signing and  reiterating the Helsinki accords  when convenient,
       it would be  of great interest to  see if the PPR  regime would
       accept an uncensored linkage to BITNET,  e.g.,  via neighboring
       Sweden.

       From the PPR government's viewpoint,   they would have to weigh
       the consequences of further 2-way  flow of information with the
       computer  know-how  to  be   gained  from  Western  scientists,
       technologists,  and  students.   The  decision made  would most
       likely  be a  technocratic one,   unless the  Soviets make  the
       decision (veto) for Warsaw.


       From:     Gabriel Basco
       Subject:  Bring BITNET to the USSR?

       About getting  the USSR into  BITNET.  Great Idea!!!!   But one
       little,  if  they don't let Western  News go in,  how  are they
       going to allow a whole bunch of  wild people like the ones that
       use BITNET, talk with their students. NO WAY!!!!!


       From:     Dave Gomberg
       Subject:  Communicating

       Steve  McClusky (sp?)   writes recently  about  those who  have
       little  or  no  reason  to   use  a  BITNET  connected  machine
       frequently,  and thus  do not receive mail  promptly.   This is
       indeed a problem.  It is analogous to a situation where I might
       rarely (or never)  check my US mailbox.   The solution for this
       case is not to hire someone to check my mailbox,  but to advise
       correspondents that  they should not expect  to reach me  by US
       mail.

       If you  are at a  BITNET institution,   but do not  access your
       mailbox  regularly,   do  not advertise  a  BITNET  address  as
       effective for  reaching you.   Advertise those  techniques that
       are effective for your behavior  patterns (US mail,  phone,  or
       whatever).   If you elect not to use your BITNET address,  that
       is your prerogative,  just as it is your choice to  have or not
       have a fax or a phone.

       It is  not the responsibility of  the telephone office  to take
       messages for you and  send them to you by courier  if you elect
       not to  have a phone.    It is  not the responsibility  of your
       BITNET site to pass material on to  you should you elect not to
       be a  BITNET participant.   Please  do not expect  the computer
       folk to be your messengers.
1

                                                               Page 23


       From:     Terence Sommerville
       Subject:  Answering unread mail

       In last month's issue of Netmonth Stephen McClusky takes up the
       issue of people not answering their VM mail.  He suggested that
       perhaps the local computer centers might generate a daily paper
       postal  listing of  who has  mail so  as  to save  the time  of
       logging on for those that rarely have time to check their mail.

       I wish  to suggest a  slightly different possible  solution for
       the same problem.  What if someone  wrote a program to scan all
       the mail as already suggested last  month,  but then to display
       this information all  day on one or two  dedicated terminals at
       the main doorways to the campus and perhaps in the library.  In
       addition it might be better if  people were also allowed decide
       whether they  wish to  be included or  excluded from  the daily
       scans of all the mail.  In  addition a dedicated server on each
       node could also hold  this data,  so that if you  were to see a
       friend of yours  logged on they could query the  system for you
       thus saving oneself the hassle of  getting them to logoff while
       you "quickly" logon to check.

       However for  some places that  could afford  it the one  or two
       terminals  could  be  expanded  to  cover  either  every  major
       entrance and or  regular meeting  places such  as main  notice-
       boards, the canteen/restaurant or perhaps even the college bar!
       If one or two sites implemented such  as system as above or the
       system using the paper listing for a trial period then it might
       give an indication as to whether  it would be worth the effort.
       For the long term I feel that it  is essential to get the "non-
       computer" people  to use BITNET and  to prove they  can benefit
       from it.  In this way whenever the issue of funds or money came
       up with respect to the site  contribution to the network,  then
       we would not have competing groups for a given amount of money,
       but  rather the  whole  community would  be  unanimous on  this
       particular issue. In the past it has been seen on BITNET as new
       programs and facilities are added new possibilities for network
       use are opened up,  which increasingly  bring in new users that
       would not otherwise dream of going near a terminal.

       At the  end of the day  this question of answering  unread mail
       can only be  answered if the whole task of  inter-facing to the
       "non-computer" type  can be made  steadily easier to  the point
       that  these people  will  then want  to  regularly check  their
       Readerlist.  In effect the job of  the normal postal system has
       to be emulated in  that the mail has more or  less to be handed
       to them on a plate.  To do  this by computer printouts would in
       the long term only generate masses  of paper most of which just
       makes  the whole  thing  more  confusing,  thus  defeating  the
       purpose of stream-lining and simplifying communications.
1

                                                               Page 24


       From:     Tony D'Angelo
       Subject:  Listserv REPRO (self copy) Option

       A while back I started inquiring why the sender of a posting to
       a list maintained by LISTSERV did not receive a copy of his/her
       message posting,   even though every  other member of  the list
       did.  Thanks  to  Jim  Gerland  (who contacted  Eric Thomas) we
       found  out  that  there  is  a  LISTSERV  distribution   option
       called "REPRODUCE  = YES" which  will implement this  self copy
       feature. The owner of the list cannot make a current list REPRO
       but he  can make  it REPRO  for anyone  who signs  up after  he
       changes the LISTSERV header for a given list.  Also,  the owner
       as the capability to change  each current member's distribution
       option to REPRO = yes.

       I would like to suggest that future LISTSERV software revisions
       have "REPRODUCE = YES" as the default condition when creating a
       list (if this hasn't already been done). I think everyone would
       always want  to receive a  copy of  his/her posting to  a list,
       just to see how it looks,  if  and when it got distributed,  if
       there are any gross errors in the message, etc.  Also,  as time
       permits,  I would  like to suggest that all list  owners at the
       various  locations  where  LISTSERV is  being  run  change  the
       distribution option of  each member of their  existing lists to
       make  them  REPRO  capable  and  change  the  list  headers  to
       "REPRODUCE = YES" for all future subscribers.

       In the meantime,  individual users can send the  SET 
       REPRO command  to any LISTSERV@  of which they  are a
       member to  activate the self  copy feature for  themselves.  To
       remove  this feature  the syntax  is   SET   NOREPRO.
       Reminder:   the  SET  command  is  sent  to  the  *LISTSERV*  @
        and *not* the .


                                                  *
       *******************************************
       *******************************************
                                                  *
                                      *
       *******************************
       *******************************
                                      *

                                                                 *
       **********************************************************
       **********************************************************
                                                                 *
                                                 *
       ******************************************
       ******************************************
                                                 *
1

                                                               Page 25

        *********
       *         *  NetMonth Policies
       *         *
       *         *  Everything you ever wanted to know...
       *         *
       *         *  ...but were afraid to ask.
       *         *
       *         *  BITLIB@YALEVM
        *********


       NetMonth is a  network service publication distributed free  of
       charge to  students  and  professionals  in  BITNET  and  other
       networks. This magazine and its companion file, BITNET SERVERS,
       are the  work  of the  BITNET Services Library (BSL) staff  and
       contributors from around the network.

       BITNET SERVERS is BITNETs list of servers and services.  If you
       know of servers not listed in BITNET SERVERS, or if some listed
       are no longer available, please contact the NetMonth Editor.

       * Subscribing to NetMonth and BITNET SERVERS:

       Send  the  following  command  to  LISTSERV@MARIST  by  mail or
       messgage:

            SUBSCRIBE NETMONTH Your_full_name

       Internet users may use this method, but must  address  the mail
       to LISTSERV%MARIST.BITNET

       * Back issues:

       BITNET users  may get NetMonth back issues from the file server
       LISTSERV@CMUCCVMA.  The  FILELIST  for these  archives is aptly
       named NETMONTH FILELIST.   Send  the  command INDEX NETMONTH to
       the server for a list of files.

       A subscriber  can delete  him/herself from  the mailing list by
       sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.

       * Letters to the Editor:  If  you  have  questions  or comments
       about BITNET or  NetMonth that you would like  to  see  printed
       here, mail  your letter  to BITLIB@YALEVM.  Make  sure that you
       specify in the "Subject:"  header or  somewhere  in  the letter
       that it is for the NetMonth letters column.

       * Article Submissions:  The  only  requirements  for   NetMonth
       articles and columns are that they be informative, interesting,
       and concern some BITNET-related topic.  Send your articles  and
       to BITLIB@YALEVM.
1

                                                               Page 26


       * Printing this file:  VM  users can print  this file  by first
       copying it to NETMONTH LISTING and then printing  the new file.
       This will allow page-breaks and other formatting to be accepted
       by your printer.


            _
           __-
          __---    The
         __-----   BITNET
        __-------  Services
       ___________ Library                       "Because We're Here."

       ***************************************************************